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FEEDBACK CANCELLATION IN A NETWORK-BASED 
TRANSACTION FACILITY 

FIELD OF THE INVENTION 

[0001] The present invention relates generally to the field of e-cormnerce and, 
more specifically, to the cancellation of feedback received from users of a network- 
based transaction facility. 

BACKGROUND OF THE INVENTION 

[0002] In addition to access convenience, one of the advantages offered by 
network-based transaction facilities (e.g., business-to-business, business-to-consumer 
and consiuner-to-consumer Internet marketplaces and retailers) and on-line 
communities is that participants within such facilities or communities may provide 
feedback to the facility, to other users of the facility and to members of an on-line 
coinmunity regarding any number of topics. 

[0003] For users of a network-based transaction facility, such as an Internet- 
based auction facility, feedback regarding other users is particxilarly important for 
enhancing user trust of the transaction facility. Indeed, a history of positive feedback 
for a trader that routinely uses an Intemet-based auction facility may be particularly 
valuable and useful in providing other traders with a degree of confidence regarding 
a specific trader. Accordingly, a positive feedback history may establish the 
credibility and trustworthiness of a particular trader within an on-line trading 
commtmity. Similarly, a history of negative feedback may discourage other traders 
from transacting with a specific trader. 
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SUMMARY OF THE INVENTION 

[0004] According to one aspect of the present invention, an exemplary method 
includes receiving a request to cancel feedback pertaining to a transaction in a 
network-based transaction facility from a first party to the transaction, determining 
whether feedback cancellation criteria are satisfied, and canceling the feedback 
pertaining to the transaction if the feedback cancellation criteria are satisfied. 
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BRIEF DESCRIPTION OF THE DRAWINGS 



[0005] The present invention is illustrated by way of example and not 
limitation in the figures of the accompanying drawings, in which like references 
indicate similar elements and in which: 

[0006] Figure 1 is a block diagram illustrating an exemplary network-based 
transaction facility in the form of an internet-based auction facility. 

[0007] Figure 2 is a database diagram illustrating an exemplary database for 
the transaction facility. 

[0008] Figure 3 is a diagrammatic representation of an exemplary transaction 
record table of the database illustrated in Figure 2. 

[0009] Figure 4 is a diagrammatic representation of an exemplary feedback 
table of the database illustrated in Figure 2. 

[0010] Figure 5 is a diagrammatic representation of an exemplary feedback 
details table of the database illustrated in Figure 2. 

[0011] Figure 6 is a block diagram of one embodiment of a feedback 
cancellation module. 

[0012] Figures 7-9 are flow diagrams of exemplary methods performed by the 
feedback cancellation module. 

[0013] Figures 10 - 24 illustrate exemplary user interfaces. 

[0014] Figure 25 is a block diagram of an exemplary computer system that 
may used to practice embodiments of the present invention. 
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DETAILED DESCRIPTION 

[0015] A method and system for canceling feedback in a network-based 
transaction facility are described. In the following description, for purposes of 
explanation, numerous specific details are set forth in order to provide a thorough 
understanding of the present invention. It wiU be evident, however, to one skilled in 
the art that the present invention may be practiced without these specific details. 

Terminology 

[0016] For the piirposes of the present specification, the term "transaction" 
shall be taken to include any communications between two or more entities and shall 
be construed to include, but not be limited to, commercial transactions including sale 
and purchase transactions, auctions and the like. 

Transaction Facility 

[0017] Figure 1 is block diagram illustrating an exemplary network-based 
transaction facility 10 that includes one or more of a number of types of front-end 
servers, namely page servers 12 that deliver web pages (e.g., markup language 
documents), picture servers 14 that dynamically deliver images to be displayed 
within Web pages, listing servers 16, CGI servers 18 that provide an intelligent 
interface to the back-end of facility 10, and search servers 20 that handle search 
requests to the facility 10. E-mail servers 21 provide, inter alia, automated e-mail 
communications to users of the facility 10. 

[0018] The back-end servers include a database engine server 22, a search 
index server 24 and a credit card database server 26, each of which maintains and 
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facilitates access to a respective database. 

[0019] The facility 10 may be accessed by a client program 30, such as a 
browser (e.g., the Internet Explorer distributed by Microsoft Corp. of Redmond, 
Washington) that executes on a client machine 32 and accesses the facility 10 via a 
network such as, for example, the Internet 34. Other examples of networks that a 
client may utilize to access the auction facility 10 include a wide area network 
(WAN), a local area network (LAN), a wireless network (e.g., a cellular network), or 
the Plain Old Telephone Service (POTS) network. 

Database Structure 

[0020] Figure 2 is a database diagram illustrating an exemplary database 23, 
maintained by and accessed via the database engine server 22, which at least partially 
implements and supports the network-based transaction facility 10 such as an 
Internet-based auction facility. It should be noted that while some embodiments of 
the present invention are described in the context of an auction facility, it will be 
appreciated by those skilled in the art that the invention will find application in 
many different types of computer-based, and network-based, commerce facilities. 

[0021] The database 23 may, in one embodiment, be implemented as a 
relational database, and includes a number of tables having entries, or records, that 
are linked by indices and keys. In an alternative embodiment, the database 23 may 
be implemented as collection of objects in an object-oriented database. 

[0022] Central to the database 23 is a user table 40, which contains a record for 
each user of the network-based transaction facility 10 such as an Internet-based 
auction facility. A user may operate as a seller, buyer, or both, within the facility 10. 
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The database 23 also includes item tables 42 that may be linked to the user . table 40. 
Specifically, the tables 42 include a seller items table 44 and a bidder items table 46. 
A user record in the user table 40 may be linked to multiple items that are being, or 
have been, auctioned via the facility 10. A link indicates whether the user is a seller 
or a buyer with respect to items for which records exist within the item tables 42. The 
database 23 also includes a note table 48 populated with note records that may be 
linked to one or more item records within the item tables 42 and/or to one or more 
user records within the user table 40. Each note record within the table 48 may 
include, inter alia, a comment, description, history or other iriformation pertaining to 
an item being offered via the facility 10, or to a user of the facility 10. 

[0023] A nimiber of other tables are also shown to be linked to the user table 
40, namely a user past aliases table 50, a feedback table 52, a feedback details table 53, 
a bids table 54, an accotmts table 56, an accoimt balances table 58 and a transaction 
record table 60. 

[0024] Figure 3 is a diagrammatic representation of an exemplary embodiment 
of the transaction record table 60 that is populated with records, or entries, for 
completed, or ended, transactions (e.g., auctions) that have been facilitated by the 
facility 10. The table 60 includes a transaction identifier colvimn 62 that stores a 
uiuque transaction identifier for each entry, and an end date column 64 that stores a 
date value indicating, for example, a date on which a transaction was established. A 
bidder column 66 stores a user identifier for a bidder (or a purchaser), the user 
identifier comprising a pointer to further user information stored in the user table 40. 
Similarly, a seller column 68 stores, for each entry, a user identifier for a seller within 
the relevant transaction. An item number column 70 stores, for each entry, an item 
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number identifying the goods or service being transacted, and a title column 72 
stores, for each entry, a descriptive title for the relevant transaction or for the item 
being transacted. A feedback column 73 stores, for each entry, data specifying 
whether feedback exists for the relevant transaction and whether this feedback is 
current (i.e., has not been cancelled). 

[00251 It should be noted that, in one embodiment, an entry is only created in 
the trarisaction record table 60 for transactions that have been established, for 
example, by the conclusion of an auction process, or by some other offer and 
acceptance mechanism between the purchaser and the seller. 

[0026] Figure 4 is a diagrammatic representation of an exemplary embodiment 
of the feedback table 52. The feedback table 52 stores summary information 
regarding feedback for users of the facility 10. The table 52 includes a user identifier 
coltimn 74 that stores, for each entry, a user identifier providing a pointer to the user 
table 40. A total score column 76 stores, for each user entry, a feedback score 
calculated by subtracting the total number of negative feedback comments received 
for the relevant user from the total number of positive feedback comments received 
for that user. A total negative column 78 stores, for each user entry, the total number 
of negative feedback comments for the relevant user, and a total positive colxmrn 80 
similarly stores, for each user entry, the total number of positive feedback comments 
received for that user. A number of retractions column 82 stores, for each user entry, 
the nimiber of bids that the relevant user has retracted from auctions. 

[0027] Figure 5 is a diagrammatic representation of one embodiment of the 
feedback details table 53, that is populated with entries reflecting the details of each 
feedback comment or opinion submitted by a user to the facility 10 regarding another 
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user or item involved in a transaction. In one exemplary embodiment, users are only 
permitted to provide feedback pertaining to a transaction upon conclusion of that 
transaction. The feedback information may pertain to the other user that participated 
in the transaction, or to the object (e.g., goods or services) that was the subject of the 
transaction. In an alternative embodiment, comments or opinions are provided 
regarding an item or service that is offered for sale or regarding an event. In these 
cases it will be appreciated that a transaction is necessarily required for feedback to 
be permitted. 

[0028] The feedback details table 53 includes an item number column 104 
including an item identifier that points to a record within the item tables 42. A 
comment column 106 stores, for each entry, the actual text of the feedback, comment, 
or opinion. A type column 108, in one embodiment, stores indication as to whether 
the comment is positive, negative, neutral, or withdrawn. A date column 110 stores, 
for each entry, the date on which the feedback, comment or opinion was delivered. 
A response column 112 stores the text of a response submitted by a user (e.g., a user 
to which the original comment pertained) in response to the comment text stored in 
column 106. Similarly, a rebuttal column 114 stores the text of a rebuttal to such a 
response. 

[0029] A feedback provider colimm 116 stores the user identifier of the user 
that submitted the original comment, stored in colimm 106, for the entry. A 
commentee coltimn 118 stores the user identifier of the user to which comment may 
have been directed. 

[0030] The feedback details table 53 also includes a withdrawal date column 
120 that stores, for each withdrawn feedback comment, the date on which this 
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feedback comment was withdrawn. 

[0031] It will be appreciated that further dates and other descriptive 
information may also populate the feedback details table 53. 

Feedback Cancellation 

[0032] Users of the network-based transaction facility 10 are allowed to leave 
feedback for other users. Feedback provides users of the transaction facility 10 with a 
degree of confidence regarding a specific user. That is, a positive feedback history 
may establish the credibility and trustworthiness of a particular user within the 
trar\saction facility 10. Similarly, a history of negative feedback may discourage other 
users from transacting with a specific user. Sometimes, feedback left for a user may 
not be accurate. For example, a feedback provider may leave a positive feedback by 
mistake (e.g., a buyer may leave negative feedback to a wrong seller) or the parties to 
a transaction may have been able to resolve the problem after negative feedback was 
left. Embodiments of the present invention provide a mechanism for canceling 
feedback in the transaction facility 10. 

[0033] In one embodiment, the transaction facility 10 contains a feedback 
cancellation module that is responsible for canceling feedback comments previously 
left by users of the transaction facility 10. Figure 6 is a block diagram of one 
embodiment of a feedback cancellation module 600. 

[0034] Referring to Figure 6, the feedback cancellation module 600 includes a 
feedback cancellation request receiver 602, a feedback cancellation criteria evaluator 
604, a feedback cancellation recorder 608, a feedback user interface (UI) generator 
612, and a database 610. The feedback cancellation request receiver 602 is responsible 
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for receiving a request to cancel feedback from a first user, identifying a transaction 
associated with the feedback and identifying a second user who was the second party 
to the transaction. The feedback to be cancelled may include feedback comments left 
by the first and second users for the relevant transaction. In one embodiment, the 
transaction is identified using an item number specified by the first user when 
submitting the request. 

[0035] The feedback cancellation criteria evaluator 604 is responsible for 
evaluating iriformation pertaining to the current feedback cancellation request based 
on a set of feedback cancellation criteria that encompass various rules for canceling 
feedback in the transaction facility 10. The rules may require, for example, that at 
least one feedback comment be associated with the relevant transaction, that the 
request to cancel feedback be received before an expiration date of the transaction, 
that each party to the transaction be currently registered with the transaction facility 
10, that the feedback cancellation request be below a threshold nimiber of allowed 
feedback cancellations for each party to the transaction, etc. In one embodiment, the 
rules require that at least one party agree to cancel feedback. 

[0036] In another embodiment, the rules require that both parties agree to 
cancel feedback. In this embodiment, the feedback cancellation module 600 also 
includes a feedback cancellation request processor 606 that is responsible for 
determining whether the second party agrees to cancel feedback for the relevant 
transaction. In one embodiment, this determination is made by notifying the second 
party about the request, presenting to the second party information identifying the 
relevant transaction and feedback left for this transaction, and receiving a 
confirmation of feedback cancellation from the second party. 
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[00371 The feedback cancellation recorder 608 is responsible for canceling the 
feedback if the feedback cancellation criteria are satisfied. In one embodiment, the 
feedback cancellation recorder 608 cancels the feedback by marking each relevant 
feedback comment as withdrawn (e.g., by recording the withdrawal date in the 
feedback details table 53), updating feedback scores (e.g., total score 76, total negative 
78 and total positive 80 in the feedback table 52), and marking the transaction as 
having withdrawn feedback (e.g., in the feedback column 73 of the transaction record 
table 60). 

[0038] The feedback UI generator 612 is responsible for generating various UIs 
that present feedback information to the users. In one embodiment, when a user 
requests to see all feedback left for some other user, cancelled feedback (if any) is 
displayed with a comment indicating that this feedback has been withdrawn. 

[00391 Figure 7 is a flow diagram of one embodiment of method 700 for 
canceling feedback in a network-based transaction facility. The method may be 
performed by the feedback cancellation module 600, which may be implemented in 
hardware, software, or a combination of both. 

[00401 Referring to Figure 7, method 700 begins with the feedback cancellation 
request receiver 602 receiving a request to cancel feedback from a first user 
(processing block 702). In one embodiment, the request includes an item identifier 
that links the request to a specific transaction. In addition, the feedback cancellation 
request receiver 602 may use the item niunber to determine the other party to the 
transaction and to retrieve all feedback conmients provided for this transaction. 
These feedback comments may be left by the first party and/or the second party. 

[00411 At processing block 704, the feedback cancellation criteria evaluator 604 

3801. PI 77 -12- 



determines whether the feedback cancellation request of the first party satisfies a set 
of feedback cancellation criteria. As discussed above, the set of feedback cancellation 
criteria are based on rules that may require, for example, that at least one feedback 
comment be associated with the relevant transaction, that the request to cancel 
feedback be received before an expiration date of the transaction, that each party to 
the transaction be ctirrently registered with the transaction facility 10, that the 
feedback cancellation request be below a threshold number of allowed feedback 
cancellations for each party to the trarisaction, etc. 

[0042] If the feedback cancellation request of the first party does not satisfy 
any of the feedback cancellation criteria, the criteria evaluator 604 creates an error 
message identifying the problem (processing block 712). If the feedback cancellation 
request of the first party satisfies all of the feedback cancellation criteria, the feedback 
cancellation request processor 606 informs the second party of the feedback 
cancellation request (processing block 706). In one embodiment, the feedback 
cancellation request processor 606 sends to the second party an email specifying the 
request and identifying the relevant transaction and feedback left for this transaction. 
The email may also include a link to a feedback cancellation form that the second 
party needs to access in order to proceed with the request. In other embodiments, 
the second party may be notified about the request of the first party using different 
communication means (e.g., a letter, a voice message, etc.). 

[0043] At processing block 708, the feedback cancellation request processor 
606 receives from the second party a response to the feedback cancellation request. 
In one embodiment, the response includes an item number that links the response to 
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the feedback cancellation request of the first party, and a request of the second party 
to view detailed information about the relevant transaction. 

[0044] At processing block 710, the feedback cancellation criteria evaluator 604 
determines whether the response of the first party satisfies the feedback cancellation 
criteria. For example, the feedback cancellation criteria evaluator 604 may determine 
whether the response is received before the expiration date of the transaction, that 
each party to the transaction is currently registered with the transaction facility 10, 
etc. 

[0045] If the response of the second party does not satisfy any of the feedback 
cancellation criteria, the criteria evaluator 604 creates an error message identifying 
the problem (processing block 712). If the response of the second party satisfies all of 
the feedback cancellation criteria, the feedback UI generator 612 presents to the 
second party information about the transaction and feedback comments left for this 
transaction (processing block 716). 

[0046] At processing block 716, the feedback cancellation request processor 
606 determines whether the second party confirms the cancellation of the feedback 
based on the input provided by the second party. If not, method 700 ends. If so, the 
feedback cancellation request processor 606 causes the feedback cancellation recorder 
608 to cancel the feedback (processing block 720). In one embodiment, the feedback 
is cancelled by marldng each relevant feedback comment as withdrawn, recalculating 
feedback scores and statistics of both parties, and marking the transaction as having 
withdrawn feedback to prevent the party who has not yet provided feedback from 
leaving new feedback. 
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[0047] In one embodiment, method 700 performed by the feedback 
cancellation module 600 is divided into an irutiator process that is based on 
interactions with the first party (referred to as a mutual feedback withdrawal 
(MFW) initiator) and a respondent process that is based on interactions with the 
second party (referred to as a MFW respondent). Figure 8 is a flow diagram of one 
embodiment of a method 800 for performing an exemplary MFW initiator process. 
Method 800 may be performed by the feedback cancellation module 600, which may 
be implemented in hardware, software, or a combination of both. Method 800 is 
discussed with reference to exemplary UIs created by the feedback UI generator 612 
and illustrated in Figures 10-15B. 

[0048] Referring to Figure 8, method 800 begins with the feedback UI 
generator 612 presenting an initial MFW UI to the first party (processing block 802). 
An exemplary initial MFW UI is shown in Figure 10. 

[0049] At processing block 804, the feedback cancellation request receiver 602 
receives an item niomber provided by the first party via the initial MFW UI and 
attempts to identify the transaction and the second party to the transaction based on 
the item number. If the item number is associated with multiple transactions and 
mtiltiple second parties (e.g., the first party is a seller who has multiple buyers of the 
same item), the feedback cancellation request receiver 602 determines that further 
identification of the transaction is required and retrieves information pertaining to 
the multiple transactions from the database 610. Alternatively, if the item number is 
associated with a single transaction, the feedback cancellation request receiver 602 
retrieves information about this trarisaction from the database 610. 
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[00501 At processing block 806, the criteria evaluator 604 determines whether 
the feedback withdrawal criteria are satisfied. Table 1 illustrates exemplary feedback 
withdrawal criteria used by the criteria evaluator 604. 



dtsaa? 1 








1 


Was an item number entered? 


Return error if FALSE 


Please enter a valid item number. 


2 


Is the user signed in and not 

suspended? 


Require sign-in 




3 


Is this a valid item number? 


Return error if FALSE 


Please enter a valid item number. 


4 


Did the user participate in this 

transaction? 


Return error if FALSE 


You are not involved in this 
transaction. 


5 


Does a specific transaction 
need to be identified? (multi- 
transaction) 


Skip to multi- 
transaction logic 




6 


Has feedback already been 
withdrawn for this 
transaction? 


Return error if TRUE 


Feedback for this transaction has 
already been withdrawn. 


6a 


Did either party leave 

fpedhflclc for tfiiQ tranQactinn*? 


Return error if FALSE 


At least one trading partner must 
leave feedback for this transaction 
before it can be withdrawn. 


7 


Less than 90 days since trxn 
end or less than 30 days since 
either party feedback left for 
this transaction? (does not 
include reply or follow-ups) 


Return error if FALSE 


This transaction is past the expiry 
date for a feedback withdrawal 
request. 


8 


Is the other party in 
transaction NARU? 


Return error if TRUE 


The request cannot be completed 
as the other party in this 
transaction is no longer a 
registered user. 


9 


MFW request already filed for 
this transaction? 


Return error if TRUE 


You have already requested 
feedback withdrawal for this 
transaction. 


10 


Is this user over their usage 
limit? 


Return error if TRUE 


You can request withdrawal for 
only 15 transactions during a 30- 
day period. 


11 


Has the other party already 
filed for MFW on this item? 


User sees respondent flow 
if TRUE. 





Table 1. 



[0051] If any of the feedback withdrawal criteria are not satisfied, the feedback 
UI generator 612 displays an error messages (processing block 816). Examples of 
error messages are included in Table 1. Figures llA and IIB iUustrate exemplary 
UIs that present error messages to the user. 
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[0052] If all of the feedback withdrawal criteria are satisfied and the item 
number is associated with multiple transactions (processing block 808), the feedback 
UI generator 612 presents to the first party a multi-item MFW UI containing a list of 
transactions. Figure 12 illustrates an exemplary multi-item MFW UI that facilitates 
user selection of a specific transaction. 

[0053] Upon receiving an identifier of the second party (the respondent) 
(processing block 812), the criteria evaluator 604 determines whether the feedback 
withdrawal criteria are satisfied (processing block 814). Table 2 illustrates exemplary 
feedback withdrawal criteria used by the criteria evaluator 604 for the multi- 
transaction items. 











IM 


Was a transaction selected? 


Return error if 
FALSE 


Please select a transaction. 


2M 


Is the user signed in and not 
suspended? 


Require sign-in 




6M 


Has feedback already been 
withdrawn for this transaction? 


Return error if 
TRUE 


Feedback for this transaction has already 
been withdrawn. 


6MA 


Did either party leave feedback for 
this transaction? 


Return error if 
FALSE 


At least one trading partner must leave 
feedback for this transaction before it can be 
withdrawn. 


7M 


Less than 90 days since trxn end or 
less than 30 days since either party 
feedback left for this transaction? 
(does not include reply or follow- 
ups) 


Return error if 
FALSE 


This transaction is past the expiry date for a 
feedback withdrawal request. 


8M 


Is the other party in transaction 
NARU? 


Return error if 
TRUE 


The request cannot be completed as the other 
party in this transaction is no longer a 
registered user. 


9M 


MFW request already filed for this 

transaction? 


Return error if 
TRUE 


You have already requested feedback 
withdrawal for this transaction. 


lOM 


Is this user over their usage limit? 


Return error if 
TRUE 


You can request withdrawal for only 15 
transactions during a 30-day period. 


IIM 


Has the other party already filed for 
MFW on this item? 


User sees 
respondent flow if 
TRUE. 





Table 2. 
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[0054] If any of the feedback withdrawal criteria are not satisfied, the feedback 
UI generator 612 displays an error messages (processing block 816). If all of the 
feedback withdrawal criteria for the multi-transaction items are satisfied or the item 
is associated with a single transaction (processing block 808), the feedback UI 
generator 612 presents to the first party an initiator review MFW UI that provides 
information about the transaction and feedback left for this transaction (processing 
block 818). Figure 13A illustrates an exemplary initiator review MFW UI. 

[00551 In one embodiment, if the first and second parties have multiple 
transactions for the same item, the feedback for each of those transactions is to be 
withdrawn at the same time and information for each of those transactions is 
included in the initiator review MFW UI as illustrated in Figure 13B. 

[0056] If the first party decides to proceed further with feedback cancellation, 
the feedback UI generator 612 presents to the first party a MFW policy UI that 
provides information about feedback canceDation rules in the transaction facility 10 
(processing block 820). Figure 14 illustrates an exemplary MFW policy UI. 

[0057] If the first party confirms the request to cancel feedback (processing 
block 822), the feedback cancellation request processor 606 sends emails to the first 
party confirming the request and to second party notifying about the request. 
Figures 21 and 22 illustrate exemplary emails sent to the first and second parties 
respectively. 

[0058] In addition, the feedback UI generator 612 presents a MFW request 
confirmation UI to the first party (processing block 828). Figure 15 A illustrates an 
exemplary MFW request confirmation UI. 
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[00591 If the first party does not confirm the request to cancel feedback 
(processing block 822), the feedback UI generator 612 presents a MFW request 
cancellation UI to the first party (processing block 828). Figure 15B illustrates an 
exemplary MFW request cancellation UI. 

[0060] Figure 9 is a flow diagram of one embodiment of a method 900 for 
performing an exemplary MFW respondent process. Method 900 may be 
performed by the feedback cancellation module 600, which may be implemented in 
hardware, software, or a combination of both. Method 900 is discussed with 
reference to exemplary UIs created by the feedback UI generator 612 and illustrated 
in Figures 16-20. 

[0061] Referring to Figure 9, method 900 begins with the feedback UI 
generator 612 presenting an initial respondent MFW UI to the second party 
(processing block 902). An exemplary initial respondent MFW UI is shown in Figure 
16. If the second party accesses the initial respondent MFW UI via email, the item 
number is included in the UI as illustrated in Figure 16. Alternatively, the second 
party is requested to enter the item number. 

[0062] When the second party asks for details of the relevant transaction 
(processing block 904), the criteria evaluator 604 determines whether the feedback 
withdrawal criteria are satisfied (processing block 906). Exemplary feedback 
withdrawal criteria used by the criteria evaluator 604 are illustrated in Table 1. 

[0063] If any of the feedback withdrawal criteria are not satisfied, the feedback 
UI generator 612 displays an error messages (processing block 913). Examples of 
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error messages are included in Table 1. Figure 17 illustrates an exemplary UI that 
presents an error message to the user. 

[0064] If all of the feedback withdrawal criteria are satisfied and the item 
nimiber is associated with multiple transactions (processing block 908), the feedback 
UI generator 612 presents to the second party a multi-item MFW UI containing a list 
of transactions to the first party, as illustrated in Figure 12. 

[0065] Upon receiving an identifier of the transaction from the second party 
(processing block 910), the criteria evaluator 604 determines whether the feedback 
withdrawal criteria are satisfied (processing block 912). Table 2 illustrates exemplary 
feedback withdrawal criteria used by the criteria evaluator 604 for the multi- 
transaction items. 

[0066] If any of the feedback withdrawal criteria are not satisfied, the feedback 
UI generator 612 displays an error messages (processing block 913). If all of the 
feedback withdrawal criteria for the multi-transaction items are satisfied or the item 
is associated with a single transaction (processing block 908), the feedback UI 
generator 612 presents to the second party a respondent review MFW UI that 
provides information about the transaction and feedback left for this transaction 
(processing block 914). Figure 18 illustrates an exemplary respondent review MFW 
UI. 

[0067] If the second party decides to proceed further with feedback 
cancellation, the feedback UI generator 612 presents to the second party a MFW 
policy UI that provides information about feedback cancellation rules in the 
transaction facility 10 as illustrated in Figure 14. 
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[0068] If the second party does not confirm the request to cancel feedback 
(processing block 918), the feedback UI generator 612 presents a MFW request 
cancellation UI to the second party (processing block 920). Figure 20 illustrates an 
exemplary MFW request cancellation UI. 

[00691 If the second party confirms the withdrawal of feedback (processing 
block 918), the feedback cancellation request processor 606 sends an email to the first 
party confirming that the request has been successfully completed. Figure 23 
illustrates an exemplary email sent to the first party. In addition, the feedback UI 
generator 612 presents a MFW success UI to the second party (processing block 922). 
Figure 19 illustrates an exemplary MFW success UI. 

[0070] Afterwards, the feedback cancellation recorder 608 marks feedback left 
for the relevant transaction as withdrawn (processing block 924), records the 
withdrawal date for each relevant feedback comment (processing block 926), and re- 
calculates feedback scores, rating totals and recent ratings for both parties 
(processing block 928). 

[0071] Subsequently, if any user of the transaction facility 20 requests to view 
feedback left either for the first or second party, the feedback UI generator 612 
presents a feedback review UI that identifies withdrawn feedback comments. Figure 
24 illustrates an exemplary feedback review UI that identifies withdrawn feedback 
2402, provides the number 2404 of withdrawn comments, and ratings and statistics 
2406 reflecting the withdrawn comments. 

Computer System 

[0072] Figure 25 shows a diagrammatic representation of a machine in the 
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exemplary form of a computer system 2500 within which a set of instructions, for 
causing the machine to perform any one of the methodologies discussed above, may 
be executed. In alternative embodiments, the machine may comprise a network 
router, a network switch, a network bridge. Personal Digital Assistant (PDA), a 
cellular telephone, a web appliance or any machine capable of executing a sequence 
of instructions that specify actions to be taken by that machine. 

[0073] The computer system 2500 includes a processor 2502, a main memory 
2504 and a static memory 2506, which communicate with each other via a bus 2508. 
The computer system 2500 may further include a video display unit 2510 (e.g., a 
liquid crystal display (LCD) or a cathode ray tube (CRT)). The computer system 2500 
also includes an alpha-numeric input device 2512 (e.g. a keyboard), a cursor control 
device 2514 (e.g. a mouse), a disk drive unit 2516, a signal generation device 2520 
(e.g. a speaker) and a network interface device 2522. 

[0074] The disk drive unit 2516 includes a machine-readable mediimi 2524 on 
which is stored a set of instructions (i.e., software) 2526 embodying any one, or all, of 
the methodologies described above. The software 2526 is also shown to reside, 
completely or at least partially, within the main memory 2504 and/or within the 
processor 2502. The software 2526 may further be transmitted or received via the 
network interface device 2522. For the purposes of this specification, the term " 
machine-readable medium" shall be taken to include any medium that is capable of 
storing or encoding a sequence of instructions for execution by the machine and that 
cause the machine to perform any one of the methodologies of the present invention. 
The term "machine-readable medium" shall accordingly be taken to included, but not 
be limited to, solid-state memories, optical and magnetic disks, and carrier wave 
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signals. 

[0075] Thus, a method and system for canceling feedback in a network-based 
transaction facility have been described. Although the present invention has been 
described with reference to specific exemplary embodiments, it will be evident that 
various modifications and changes may be made to these embodiments without 
departing from the broader spirit and scope of the invention. Accordingly, the 
specification and drawings are to be regarded in an illustrative rather than a 
restrictive sense. 
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